The universal plug and play UPnP protocol constitutes a set of computer network protocols allowing devices to connect seamlessly and to simplify the implementations of networks for data sharing, communication and entertainment. Furthermore, the UPnP is a device control protocol which is built upon open internet-based communication standards. The UPnP architecture allows a peer-to-peer networking of personal computers, network appliances and wireless devices. The UPnP architecture is an open architecture based on TCP/IP, UDP and HTTP. The UPnP architecture is described on http://www.upnp.org/resources/upnpresources.zip. The UPnP networking is relying on IP addressing. Therefore, each device must have a dynamic host configuration protocol DHCP client and search for a DHCP server when it is connected to the network. If no DHCP servers are available, the device must assign itself an IP address.
The UPnP protocol is based on several steps, namely discovery, description, control, event notification and presentation. In the first step, a discovery of a device within the network based on its IP address is performed. In the next step, a device description must be performed. After a UPnP control point has discovered the device, the control point must retrieve the device description for example from the Uniform Resource Identifier URI provided by the device in the discovery message. The description may include the model name, number, serial number, manufacturer name, etc. In the next step, the control point can send actions to the device to control the device and the services of the device. A further step in the UPnP protocol is the event notification. An UPnP description for a service may include a list of actions to which the service will respond to as well as a list of variables that may model the state of the service at run time. The service may send event messages (names of one or more state variables and current value of these variables). Finally, a control point may retrieve information (like a page from the URL of the device) and load this information for example into a web browser.
The UPnP may also be applied to audio and video. Here, a UPnP media server may be a UPnP server sharing or streaming media data to UPnP clients or renderers in the network. An UPnP media server control point is a UPnP client which can also detect UPnP services on the network to browse and stream media and data files on the UPnP servers, in particular the content directory service CDS of the servers. An UPnP media renderer is a device rendering content. An UPnP rendering control DCP enables a control of the media renderer settings like volume, brightness, RGB, sharpness, etc.
FIG. 1 shows a schematic representation of a basic UPnP AV audio video architecture. An UPnP control point, a UPnP renderer and a UPnP server is provided. The UPnP control point CP is used to discover the UPnP devices in the UPnP network, i.e. it finds or discovers the UPnP server US and the UPnP renderer UR. It is also possible the UPnP control point CP and the UPnP renderer UR are combined into a single (physical) device. In such a case, the use of a local UPnP renderer UR is applied and only the UPnP server and its content will be located through the UPnP protocol based on the content directory service CDS.
When the UPnP server US has been discovered by the UPnP control point CP, the control point will browse or search through the content directory service CDS. In the content directory service, a list of content items tagged as <item> may be present. Each individual <item> will contain an amount of metadata like a resource tag as <res>. The <res> provides a link to the actual physical content (URL). The <res> metadata may contain information regarding the encoding of the content which may be part of the protocol info. The control point CP will compare and match the information regarding the encoding of the content with the decoding capabilities of the UPnP renderer. Thereafter, the control point CP may present a list of content to the end user which is then able to select a particular content to be rendered. The control point CP can also be used to accordingly instruct the UPnP renderer UR to play the desired content. This may be performed by a HTTP player HP in the renderer UR which receives HTTP streaming data from a HTTP server HS in the UPnP server. However, if the control point CP can not find the required encoding of the <item> in the content directory service CDS, a transcoder is required to provide for the required encoding of the <item>.
An UPnP server may therefore comprise a transcoder to provide multiple formats of the content on the server. The transcoding can either be generated off-line or on-line. The network transcoder can also be implemented as a separate UPnP entity with its own UPnP-CDS content directory service. The content directory service CDS may contain links to original content items on other UPnP servers in the network. It may contain links to alternate encodings of these content items by providing additional <res> for those <items>. In other words, the UPnP transcoder indicates alternate encodings as part of its own UPnP-CDS. The UPnP transcoder re-exposes all content it can find on the network in all possible encodings. As a result, a great number of extra <res> entries in its content directory service may be present, which may not be required.
<res> is an XML tag returned by the UPnP-CDS as a result of a browse or search action. The browse or search result contain a list of content items which may be tagged as <item>, wherein each individual <item> carries an amount of metadata. The <res> is part of this metadata and provides a link to the actual physical content, this link can be URL. Therefore, several <res> for a single <item> are allowed. In other words, multiple URL are allowed for a single <item>. The <res> may be provided to indicate an alternate encoding of the content.
US 2005/0138137 describes UPnP network where URL are parameterized to indicate the desired encoding.
US 2005/0235077 discloses a network transcoder. This is performed by matching source and the destination with a transcoder or formatter in between to perform the required transcoding.
Although the above described transcoder allows the provision of additional encodings for other UPnP AV servers on the network, these additional encodings are only exposed through content directory service CDS of the transcoder but not through the CDS of the original server. Accordingly, to find the required encoding of <item>, the end user may have to search in the transcoder server instead of the original server to locate the required encoding. This is clearly not a transparent implementation and is therefore not easy to use. Furthermore, prior art network transcoders may re-expose all content it can find on the network in all possible encodings which may lead to an excessive number of additional <res> entries which are not required.